contracts/token/ERC20/extensions/ERC4626.sol (1)

302-310: Well-designed hooks with clear default implementations.

The introduction of _transferIn and _transferOut as internal virtual functions elegantly solves the issue raised in #5960. Key strengths:

• The virtual modifier enables customization without forcing implementers to skip super._deposit/super._withdraw
• Default implementations maintain backward compatibility using SafeERC20
• Clear function names that indicate directionality
• Proper separation of concerns

Optional: Consider enhancing documentation.

While the current brief comments are adequate, you could optionally add more detailed NatSpec documentation for these hooks, such as:

-    /// @dev Performs a transfer in of underlying assets. The default implementation uses `SafeERC20`. Used by {_deposit}.
+    /**
+     * @dev Performs a transfer in of underlying assets from `from` to the vault.
+     *
+     * The default implementation uses `SafeERC20.safeTransferFrom`. Used by {_deposit}.
+     *
+     * IMPORTANT: When overriding this function:
+     * - Ensure assets are securely transferred or accounted for
+     * - Consider updating {totalAssets} if assets are held elsewhere (e.g., staking)
+     * - Maintain reentrancy safety by preserving transfer-before-mint order in {_deposit}
+     * - Update preview functions if the override affects conversion rates
+     */

Additionally, the contract header's override guidance (lines 52-68) could mention these hooks as another customization point alongside _deposit and _withdraw.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro